fix(dbt-tools): move to dbt-integration 0.3.15 so the dbt adapter starts under Bun - #1368

Issue for this PR

Closes #1367

Type of change

• Bug fix

What does this PR do?

Moves packages/dbt-tools from @altimateai/dbt-integration 0.2.14 to ^0.3.15. 0.2.x started its Python child through python-bridge, which fails under Bun (bluebird.promisifyAll on child_process throws Cannot access invalid private field (evaluating 'this.#stdin')), so the dbt-first path of sql_execute never ran. 0.3.x vendors the bridge and uses a plain fd-3 pipe; python-bridge and bluebird leave the lockfile. From 0.3.15, a bridge running inside a single-file executable writes its script to a temporary directory and removes it on exit, so the compiled binary starts the bridge too.

• adapter.ts: 0.3.x's DBTProjectIntegrationAdapter takes a UnitTestParser and a SemanticModelParser; the Fusion integration no longer takes the cloud-variant detector (the Cloud integration still does).
• copy-python.ts / release.yml / publish.ts: the vendored bridge finds node_python_bridge.py from the bundle's own location at runtime (fileURLToPath(import.meta.url)), so the python-bridge __dirname patch is gone. The build and the release smoke check now assert the new resolution instead of the patch.
• Tests: build-adversarial.test.ts tested the removed patch. The checks in it that don't depend on the patch move to build-integrity.test.ts (no build-machine path in the bundle, Python packages copied, createRequire, byte-identical rebuilds). A new test runs the package as publish.ts lays it out, from another directory, and checks that it starts the bridge script next to its own bundle.

Claims

• C1: Under Bun, the dbt-first path of sql_execute starts the dbt adapter and runs the query through dbt, from source and from the compiled binary.
• C2: The compiled binary runs the bridge from a real directory, not from /$bunfs. No Python process and no temporary bridge directory is left after the call.
• C3: altimate-dbt, laid out as publish.ts ships it and run by Node from another directory, starts the node_python_bridge.py next to its own bundle. The build and the release smoke check fail if a build-time path is baked into the bundle.
• C4: adapter.ts builds the adapter with what 0.3.x's constructors take: both new parsers, and the cloud-variant detector for dbt Cloud only.

Residuals

• R1: 0.3.15 was published on 2026-10-13, inside this repo's 3-day minimumReleaseAge. The lockfile pins it, and Bun applies that window only when it resolves a version, so installs from the lockfile take 0.3.15. The lockfile change for it is that one entry; its dependencies are the same as 0.3.13's.
• R2: When the adapter can't start (no dbt in the venv, a broken project), sql_execute still falls back to the configured warehouse without saying why. That's unchanged by this PR.

How did you verify your code works?

sql_execute called through the real tool registry (debug agent build --tool sql_execute, no model turn), against a two-model dbt-core 1.11.7 / DuckDB project with its own venv, query select count(*) as n from customer_totals:

• Compiled binary: the bridge ran as /tmp/altimate-dbt-integration-<random>/bridge.py. Python processes were sampled every 200 ms; none was left after the call, and neither was the temporary directory.
• From source, the bridge ran from @altimateai/dbt-integration@0.3.15/dist/node_python_bridge.py.
• altimate-dbt as npm ships it (publish.ts layout, Node 22, run from another directory), execute --query …: [{"n": 2}], as on main.
• packages/dbt-tools: typecheck clean, build verified, 88 tests pass. The relocation test fails when a fixed path is baked into the bundle. packages/opencode: typecheck clean.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

Appendix: complexity delta

✅ No touched function changed in complexity (2 touched, 0 new, all under 10). Advisory, not a gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_0172qrhMa5TQgETASi5hxMqD